SaaSサービスのアクセスにCloudflare Accessを介したIdPプロキシをやってみる

Cloudflare Accessとは

Cloudflare Access とは Cloudflare Zero Trust の一部のサービスで、組織内のアプリケーションにセキュアにアクセスするために、アクセス制御ポリシーを提供するサービスとなります。
IdP統合やデバイスポスチャ、WARPなど様々な機能と連携して利用することが可能です。
一言ではアクセス制御ポリシーを提供するサービスとなりますが、製品の名前の通り、ゼロトラストアーキテクチャを実現するため、最小権限の原則を基本とし、認証・デバイス・場所・その他のコンテキストのいずれかの情報だけに依存しない方法でリソースのアクセス権限を付与することができるような設計となっております。

またゼロトラストアーキテクチャの実現には、この中でもアクセスに対する認証の機能実装が重要な要素となってきます。Cloudflare Zero Trust自身にはIdP機能は持っていませんが、IdP統合が可能となっています。

Cloudflare Zero TrustへのIdP統合をやってみたブログ：

では、IdPを統合した後、どうやってCloudflare Zero Trust（Cloudflare Access）・IdP・SP間の通信が行われるのでしょう。
こんなイメージで、SPからはCloudflare AccessはIdPプロキシとして振る舞います。
SP-Initiated:

SSOではSP-InitiatedとIdP-Initiatedとがあり、上記はSP-Initiatedとなります。IdP-Initiatedは以下のようなイメージです。
IdP-Initeated:

それぞれの通信の特徴については、こちらに分かりやすい例がございましたのでご参照ください。

やってみる

では早速やってみます。
Cloudflare Access に登録可能なリソースのタイプは主にSaaSと自社がホスティングしているサービスの2種類になります。
SPとIdP関係のあるSaaSをCloudflare Accessにつなげてみたいと思います。

SaaSをCloudflare Accessにつなげるには、SAMLまたはOIDCを利用します。

Cloudflare AccessはIdPプロキシとして振る舞います。そのため、Cloudflare AccessとSPで信頼関係を結びます。一方でCloudflare AccessとIdPとでも信頼関係を結びます。
上記のブログでのAzure ADをIdPとして統合ができていることを前提に行っていきます。

尚、SPはSaaS型SIEM製品である Sumo Logic を使い、SP-Initiated構成とします。Sumo LogicはCloudflareのログ連携のための統合製品としても利用できますが、今回はあくまでSSOのテストのためのSPとして利用します。

最初にCloudflare Zero Trustの管理コンソールにログインします。

Access > ApplicationsでAdd an applicationを選びます。

SaaSを選択します。

Applicationのセレクトボックスでは、Sumo Logicはないので、ないSaaSの場合は入力して選択します。
Entity ID、Assertion Consumer Service URL、NAME ID Formatを入力します。
（Sumo LogicのSSO設定では、SP-Initiatedの場合、環境毎のEntity IDとAssertion Consumer Service URLになります。こちらを参照）

Application Appearanceは主にIdP-Initiatedの時の設定になりますので、App Launcher VisibilityをOffにします。

Identity ProvidersはCloudflare Zero Trustに登録しているIdPのうち、どのIdPによる認証を行うかを選択します。例えば、M&Aによって異なるIdPや、一時的に外部組織のユーザーのメールアドレスによるOne Time PINを有効にして組織間でのコラボレーションを実現することができます。
今回は、Accept all available identity providerはOnにしてOne-time PINとAzure ADを有効にしてみます。

画面上部に戻って、Nextをクリックします。

次にポリシーの設定をしていきます。このSaaS用のポリシーを作成するかGroup Policyを設定します。

ポリシーを作成する場合はRuleを設定していきます。少なくとも1つのIncludeルールが必要です。 とりあえずは、Login MethodsとAzure ADを選択します。

他にも、IP Rangeや国、Warpをインストールしているかなどを複合的にチェックすることで、デバイスの状態や場所などのコンテキストを接続条件に加えることができます。

再度画面上部に戻って、Nextをクリックします。

これで、Cloudflare Accessの設定は完了しました。

SSO endpointのURLの最後に/saml-metadataをつけて（「https://<your-team-name>.cloudflareaccess.com/cdn-cgi/access/sso/saml/<app-id>/saml-metadata」）、WebブラウザでアクセスするとIdP Metadataが取得できるので、これをダウンロードしておきます。（※Cloudflare Accessの設定後、少し時間が立たないとメタデータが表示されないことがあるようです）

今度はSP側の設定になります。Sumo Logicの管理コンソールにアクセスします。

左ペインでAdministration > Securityに進み、上部SAMLを選択の上、+Add Configurationに進みます。

　　

Configuration Nameを入力して、Import Metadata XMLを選択します。

先程ダウンロードした、メタデータファイルをアップロードします。

残りの設定が補完されるので、Addで設定を完了させます。

これで設定ができたので、ログインを試してみます。

Sumo Logic のポータルへのログイン画面を開き、Azure AD Cloudflare からログインを試みます。

そうすると、Cloudflare Zero Trust へリダイレクトされ、ログイン方法を選択できます。Azure ADを選択してきます。

次に実際のIdPである、Azure AD の認証画面にリダイレクトされ、IdP認証するアカウントを選択します。

認証が成功すると、もう一度 Sumo Logic にアクセスが返され、ログインすることができました。

サインアウトすると、Cloudflare の画面が表示され、ログアウトができました。

まとめ

いかがでしたでしょうか。他のSPとなるSaaS製品や認証基盤として使用するIdPが今回の製品と異なる場合は、その設定内容も若干異なってくるとは思いますが、大まかな動きについてはイメージしていただけたのではないでしょうか。

また Cloudflare Access がIdPプロキシとして介在することでデバイスポスチャのアクセス制御がかけれたり、複数の認証基盤を統合することができました。
このようにして、ゼロトラストアーキテクチャへの実装に近づけることができましたね。

ぜひ、Cloudflare Zero Trust でセキュアでかつパフォーマンスの高いネットワークアクセスを試してみてください。